By David P. Friedlander

Consider a Career in Actuarial Software

Looking for a
change in direction? Software may be calling your name.

Half of my job as a chief actuary at a software company is to help
design software that complies with the Actuarial Standards of Practice and
the applicable laws and regulations. Then I have to make sure the end product
is in accordance with the designs. The other half of my job is to train and
support the software users.

Today, nearly all
actuaries use computer software and most use software tools that are
designed specifically for actuaries. Some are at least partly designed by
their fellow actuaries. However, actuaries are also frequently involved in the
design of software tools that are used mainly by non-actuaries. If you’re
an actuary who enjoys working with computers, this could be the career path for
you.

Communication Skills Are Key

My own firm is always looking for the few people who have that
elusive combination of actuarial, communication, and technology skills
that make it possible to work smoothly with both the technology who actually
develop the code and the clients who use it. For our company, those end
users are employee benefits professionals. However, other software firms
that employ actuaries produce tools used by life insurance actuaries, casualty
actuaries, underwriters, and others.

Those of us who work with software firms find ourselves
both training and supporting the actuaries and actuarial assistants who use the
software. These people are usually well versed in actuarial principals but
often know very little about computers. We also need to provide design
specifications to technology professionals who know far more than we do about
computers but may not know the difference between an actuary and a
mortuary. Therefore, we need all of the communications skills that a consulting
actuary needs as well as an understanding of computers.

In order to
communicate actuarial principals to technology professionals, we need
to have a very thorough understanding of those principals. It’s the same
kind of understanding required to pass actuarial examinations, although,
unlike some other environments in which actuaries work, software firms usually
consider the quality of their work much more important than examination-based
credentials when they judge their employees.

A software
product has to anticipate many different scenarios, some of which probably were
not included in the limited number of questions that could be included on
an examination. For example, a product that calculates optional forms of
pension benefits has to account properly for the participant whose benefits
are the regulatory maximum benefit under the normal form of payment but not
under the selected optional form and vice versa. On the other hand, it also has
to account properly for the person whose benefit is so small that the option
isn’t permitted at all, along with the vast majority of cases that fall
between these extremes.

As an actuary who has been in the software development
environment for 30 years, I’ve witnessed incredible changes in the data
processing environment. In this field, the one thing that’s certain
is change, so one has to be very flexible.

In the 1970s, almost all actuarial software resided on
mainframe computers, often the so-called super computers (far from
“super” by 2005 standards) that were manufactured by the now
defunct Control Data Corporation. In those days, programs were laboriously
created on punch cards, one instruction per card, and woe to anyone who dropped
one of those decks if the cards weren’t properly numbered!

By the early 1980s, much of the software had migrated
to mini-computers manufactured by other poorly remembered companies such
as Prime Computing and Digital Equipment Corporation. I still remember
authorizing a purchase in 1982 for a 300 megabyte disk drive that was the size
of a desk, had a removable disk platter weighing more than 50 pounds, and
cost about $20,000. (Today, a $300 MP3 player has 100 times more disk space,
fits in my shirt pocket, and weighs 4 ounces.)

Later in the 1980s, the tools appeared on DOS-based
personal computers. Of course, personal computers still dominate today,
although DOS is nearly forgotten and has been replaced by various
versions of Windows. Each of these advances, along with the well-known changes
in the regulatory environment, has required that the software tools be largely
rewritten and, therefore, has created new opportunities for those of us in
the software development field.

In addition
to these changes, the tools themselves have become far more complex, so that it
now requires a team of technology professionals to write the actual code. By
comparison, as recently as the 1980s, actuarial software firms were often
staffed entirely by technology savvy actuaries and employed few or
sometimes no technology professionals. In those days, all that was expected of
the tools was that they produce the correct answers. Output didn’t
need to be attractive because it was manually transcribed before delivery
to the end user and nobody expected results to arrive in less than an hour.

Today, we expect instant results that can be conveyed to
the end user and with almost no work to be done by the operator of the tools.
We also expect everything to run remotely via the Internet. What all this
means to actuaries who work at software firms is that we have to communicate
our science to technology professionals instead of write code. Communications
skills have become more important to us than programming skills.

None of this means that anyone can work at a software
environment without understanding data processing. We still have to know how to
write programming specifications that are acceptable to technology
professionals, and this requires an understanding of database technology.
Modern databases are accessed using a tool called SQL (sometimes
pronounces as Sequel) and it’s very helpful for actuaries in this environment
to know that tool. It’s also very useful to be able to read and
“debug” actual code and even to be able to write small patches of
that code (often referred to as “entry point programming”).

Breaking
the Code

Programming
code is written using tools called programming language, so these skills
require a familiarity with those tools. The most modern code is written in the
following languages: C++, C# (pronounced C-Sharp), DELPHI,
Visual BASIC, and FORTRAN. However, we often also have to work with older code
that can be more economically maintained than rewritten. This code is also
written in FORTRAN, BASIC (the predecessor of Visual BASIC) and PASCAL (the
predecessor of DELPHI). However, it may
also be written in dying languages such as COBOL and APL, so it’s useful
to know those too.

It’s also worth noting that the majority of actuaries
who work in software development companies are either enrolled actuaries
or associates of the Society of Actuaries or the Casualty Actuarial Society,
rather than fellows of those organizations. Because it’s one of the
areas in which an actuary can work without passing as many examinations,
the extra time we spend learning about computers may be at least partially
offset by fewer hours of formal studying.

To summarize, working at a software company is a choice to
consider if you’re a strong technical actuary with excellent
communications skills, you’re able to deal with frequent changes to the
environment in which you work, and if you enjoy working with computers and know
more about them than most of your fellow actuaries. It’s an option that may
not require completing all of the fellowship examinations if you have technical
strengths that offset a lack of credentials.

David P. Friedlander is principal and chief actuary at Lynchval
Systems Worldwide in Chantilly,
Va.